\chapter{Project Analysis | Tobias Lauffer}\label{chap:projectAnalysis}

\section{Condition for Project Success}
The condition of the projects success does have different facilities. On the one hand it is important to show the stakeholder that they bought a reliable, sustainable and comfortable product, which exactly fits their use case and offer additional features. 

\noindent
On the other hand a resilient project management especially with its risk management is very important. Risks should be minimized as far as practical. Additional the time for realizing the requirements must be calculated as exact as possible.

\section{Stakeholder Identification}
The stakeholders are classified into major and minor stakeholders.

\subsection{Major Stakeholders}
\begin{itemize}
	\item Technical Academy Esslingen (TAE)
	\item Brunel University
	\item Prof. Dr. Karim Khakzar
	\item M.SC Dipl.-Inf. (FH) Hans-Martin Pohl
	\item Team Green
\end{itemize}

\subsection{Minor Stakeholders}
\begin{itemize}
	\item Customers
	\item Environmental industry
	\item Credit institutes
	\item Provider of server
\end{itemize}

\section{Requirements Engineering}
This chapter will focus on functional and non-functional requirements, which the system needs to perform. The requirements are divided into three categories, which describe the realisation priority of them. These criteria are:
\begin{description}
	\item[Have to] If a criterion has this label it has to be implemented in the web shop. If the requirement is not implement the project can not be approved.
	\item[Optional] It is recommended implementing requirements with this label. These requirements are usually features and they do not have influence on the main functionality.
	\item[Future] These are requirements, which may have a great meaning in the future but cannot be implemented at present.
\end{description}

\noindent
As requirements engineering tool Enterprise Architect  was used, which is an UML tool for business modelling. The advantage of this tool is that the whole system development process can be depicted in one tool, from the engineering process with use cases and requirements over planning of the architecture as well as the implementation and the test cases which can be mapped directly to the requirements (see also chapter \ref{chap:testing}).

\subsection{Top level Requirement}
The system is a browser based web shop, which sells environmental friendly products.

\subsection{Functional Requirements}
This chapter describes in different paragraphs the functional requirements of the web shop system. The requirements are grouped in related requirement groups.

\subsubsection{Customer Registration and Login (have to)}
\begin{description}
	\item[REQ010 - Create a customer account] A customer of the web shop can create an account. The customer has to deliver a username, which is a valid e-mail address, and an appropriate password. Additional the address of the user has to be added, which will be used as default delivery address.
	\item[REQ020 - A customer shall be able to enter and edit personal data] A customer can edit its personal data and add additional addresses where products can be sent to.
	\item[Customer login] The web shop provides a login for registered Users of the portal. When the user is not logged in the user will be handled as guest. A guest user can browse products and read customer reviews of other users. Additional a registered user can select products, which will taken in a shopping basket and write reviews for products, which was bought in an earlier session.
\end{description}

\subsubsection{Product Handling (have to)}
\begin{description}
	\item[REQ040 - See products and read additional information] Products are depicted with their picture, price, product description and an alternative advertising video. Additional the inventory and customer reviews should be shown if available.
	\item[REQ050 - Rating and review] A product that was delivered to a customer can be rated and reviewed by them. Therefore a user writes a text with his experience of the product. Additional a rating with five possible stars can be given.
	\item[REQ060 - Product search] A product can be searched over a web shop internal search mechanism.
\end{description}

\subsubsection{Buy Products (have to)}
\begin{description}
	\item[REQ070 - Buy products] The selected products which were placed into the shopping cart can be ordered over a "Buy now" button. If the user is already logged on, the user will be asked for the destination address. If there was earlier an address added this will be set as default. Additional the user can add a new one. If the user is not logged on, either he has to log on or has to create a new Account.
	\item[REQ080 - Shopping cart]The system has a Shopping cart (basket) which shows the products that were earlier selected over a "Buy" button from a user. The shopping cart shows the title and the price of the product, as well as the total price of all products.
	\item[REQ090 - Payment] The web shop has payment functionality, with the options "bill per lastname", "credit card" and "transaction". The transaction functionality will be outsourced to another provider.
	\item[REQ100 - Confirmation E-Mail] The web shop system will send a confirmation mail for the order to the customers e-mail address. For this the system uses the e-mail address of the username.
\end{description}

\subsubsection{Newsletter (have to)}
\begin{description}
	\item[REQ110 - Newsletter subscription] A user can subscribe for a newsletter. Therefore a valid e-mail address hast to be provided. The newsletter will be send frequently to this e-mail address.
	\item[REQ120 - Newsletter un-subscription] If a user has subscribed a newsletter, the letter can be un-subscribed over a link in the e-mail.
	\item[REQ130 - Newsletter confirmation] Before a newsletter can be received, the user gets a confirmation e-mail that he wants to have the newsletter. In this e-mail a confirmation link has to be executed as security mechanism against email privacy.
\end{description}

\subsubsection{Web Shop Administration (have to)}
\begin{description}
	\item[REQ140 - Separation of roles] The web shop provides a separation of roles for employees who work administratively at the web shop.
	\item[REQ150 - Create administrator account] A administrator of a the web shop can give the administrator privilege to other users and create administrative accounts.
	\item[REQ160 - Administrator login] An Administrator can login to the administrative system over an e-mail address an appropriate password.
	\item[REQ170 - Product management] There are additional roles like a product care and maintenance role which is only responsible for the products.
	\item[REQ180 - User management] There is an additional role for caring and maintenance of users.
	\item[REQ190 - Advertising management (e.g. newsletter)] Further there is a privilege for advertising management.
\end{description}

\subsubsection{Additional Features (optional)}
\begin{description}
	\item[REQ200 - Currency in Euro and Dollar] A customer can pay with Euro or Dollars.
	\item[REQ210 - Wishlist] A user can create a wish list when logged on to the system. This wish list can be edited. A product can be inserted or deleted.
	\item[REQ220 - Top of the shop] "Top of the shop" can show featured articles on the start page.
	\item[REQ230 - Week special] "Week special" shows a special featured product of the week on the title page.
	\item[REQ240 - Order history] The order history shows all previous orders on the web shop. The period will reach a time of 2 years.
	\item[REQ250 - Question for a product] A user can ask questions for a product. The question will be sent to the shops mail address.
\end{description}

\subsubsection{Additional Features (future)}
\begin{description}
	\item[REQ300 - Cross platform marketing] The system can connect to the Amazon reseller interface. This mechanism shall improve to sell more products.
\end{description}

\subsection{Non-functional Requirements}
The chapter describes the non-functional requirements of the web shop system. This includes architectural aspects, system aspects as well as performance aspects.

\subsubsection{Architectural Aspects}
\begin{description}
	\item[REQ500 - Frontend as Webpage over HTTP] The graphical user interface will be realized as Web-Site, which will be deployed on a web-server. This frontend is accessible over an Internet browser with an HTTP hyperlink.
	\item[REQ510 - Backend as Webpage over HTTP] The administrative console for the web shop will be reached over an Internet browser and an HTTP hyperlink. The administrative users has to login with a username and a password.
\end{description}

\subsubsection{System Aspects}
\begin{description}
	\item[REQ520 - Runnable on common browsers] The web shop must be runnable on the common Internet browsers Internet Explorer, Mozilla, Firefox and Google Chrome.
	\item[REQ530 - Webshop is free software] The web shop is a free existing and established software which can be downloaded from the Internet.
	\item[REQ540 - System is small] The web shop software system does have a maximum size of 50MB.
	\item[REQ550 - System is easy to install] The whole installation process is completed in one business day (BD).
	\item[REQ560 - System is simple to administrate] The system is simple and self-explanatory to administrate.
\end{description}

\subsubsection{Performance and Capacity Aspects}
\begin{description}
	\item[REQ570 - Response time] The web shop in sell modes has a maximum response time of 5 seconds.
	\item[REQ580 - User traffic] The system can handle 100 users at the same time.
	\item[REQ590 - Orders] The system can handle 20000 orders a year.
\end{description}

\section{Risk Management}
The chapter lists potentially risks in the following paragraphs that might have an essentially effect on the results of the project. Further possible solutions will be defined that should reduce each risk. Every risk will cover and evaluate the issues probability, priority and impact with the categories low, medium and high.

\subsection{Losing a Team Member}
In case of losing a team member the tasks will be distributed equally to the other team members.
\begin{description}
	\item[Probability] medium
	\item[Priority] very high
	\item[Impact] medium (dependent on how many members will get lost)
	\item[Solution] Work packages will be made smaller, so that they can be distributed equally to the other team members in backup.
\end{description}

\subsection{Loss of Server}
A server may crash or has malfunctions.
\begin{description}
	\item[Probability] medium
	\item[Priority] high
	\item[Impact] high
	\item[Solution] A backup server has to be provided. Additional an image of the running web shop has to be created, which will be recovered on the backup server.
\end{description}

\subsection{Loss of Infrastructure}
Between the possible losses of the server also the network infrastructure might fail.
\begin{description}
	\item[Probability] low
	\item[Priority] medium
	\item[Impact] high
	\item[Solution] Change to a data center with redundant infrastructure.
\end{description}

\subsection{Vulnerable Web Shop}
The web shop might have security leaks and could be vulnerable to an attacker.
\begin{description}
	\item[Probability] medium
	\item[Priority] high
	\item[Impact] high
	\item[Solution] Update framework with a newer version, if the security leak is closed in this version. Otherwise change to another web shop framework.
\end{description}

\subsection{Payment Risks}
This issue includes three cases. The payment system is not available. The customer doesn't want to pay. The payment system has a security leak.
\begin{description}
	\item[Probability] low / high / low
	\item[Priority] high / high /high
	\item[Impact] medium /medium / high
	\item[Solution] If the payment system is not available the web shop can offer other payment functionalities. A customer that does not pay can be avoided by appropriate payment models. On a security leak the respective method must be disabled in the web shop.
\end{description}

\subsection{Project Plan Risks}
Maybe wrong estimations would have strong effects on later project phases.
\begin{description}
	\item[Probability] high
	\item[Priority] high
	\item[Impact] high
	\item[Solution] A continuous communication of all members and their state can minimize this problem and leads to an early realization of bottlenecks.
\end{description}

\section{Personas}
This chapter shall give an overview of possible personas that want to use the online shop from GreenGadget Inc. This procedure shall help to show the developers possible use cases that might appear in a daily business use of the web shop. For each person the personal data, the aims and skills are described.

\subsubsection{Brad P.}
\begin{itemize}
	\item Age: 48
	\item Actor
	\item Uses Internet regularly
	\item Has a lot of experience with buying products online
	\item \textit{"I want to find cool stuff with lifestyle"}
\end{itemize}

\subsubsection{Joschka F.}
\begin{itemize}
	\item Age: 10
	\item Wants to become a politician
	\item Has basic experiences in using the Internet
	\item Has never used a online store before
	\item \textit{"I am interested in everything that runs with solar power"}
\end{itemize}

\subsubsection{Stefanie G.}
\begin{itemize}
	\item Age: 42
	\item Sportswoman
	\item Uses Internet sometimes
	\item Buys sometimes things on online shops
	\item \textit{"Sporty. Environmentally. That's my thing"}
\end{itemize}

\begin{figure}
  \centering
  \subfloat[Brad P.]{\label{fig:brad}\includegraphics[width=0.3\textwidth]{images/brad}}
  \subfloat[Joschka F.]{\label{fig:joschka}\includegraphics[width=0.3\textwidth]{images/joschka}}        
  \subfloat[Stefanie G.]{\label{fig:steffi}\includegraphics[width=0.3\textwidth]{images/steffi}}
  \label{fig:animals}
\end{figure}